Recently there have been several threads where the problem at hand lends itself to using SSE2 SIMD intrinsics. These are convenient because on 64-bit x86 the instructions are always present and so don't need a runtime check. To integrate them into our code base, we will need to take some measures for portability, but after looking around it seems fairly lightweight: 1. Compiler invocation and symbols Since SSE2 is part of the AMD64 spec, gcc enables it always: $ gcc -dM -E - < /dev/null | grep SSE | sort $ gcc -dM -E -msse2 - < /dev/null | grep SSE | sort #define __MMX_WITH_SSE__ 1 #define __SSE__ 1 #define __SSE2__ 1 #define __SSE2_MATH__ 1 #define __SSE_MATH__ 1 Passing -m32 discards the "MATH" macros but keeps the rest: $ gcc -dM -E -m32 - < /dev/null | grep SSE | sort #define __SSE__ 1 #define __SSE2__ 1 Clang behaves similarly. MSVC doesn't define __SSE2__ (although it does define __AVX__ etc), but we can just test for _M_X64 or _M_AMD64 (they are equivalent according to [1], and we have both in our code base already). We could test for __SSE2__ for 32-bit gcc-alikes in the build farm, but I don't think that would tell us anything interesting, so we can just test for __x86_64__. 2. The intrinsics header From Peter Cordes on StackOverflow [2]: ``` immintrin.h is portable across all compilers, and includes all Intel SIMD intrinsics, and some scalar extensions like BMI2 _pdep_u32. (For AMD SSE4a and XOP (Bulldozer-family only, dropped for Zen), you need to include a different header as well.) The only reason I can think of for including <emmintrin.h> specifically would be if you're using MSVC and want to leave intrinsics undefined for ISA extensions you don't want to depend on. ``` It seems then that MSVC will compile intrinsics without prompting, so to be safe we'd need to take the latter advice and use <emmintrin.h>. 3. Support for SSE2 intrinsics This seems to be well-nigh universal AFAICT and doesn't need to be tested for at configure time. A quick search doesn't turn up anything weird for Msys or Cygwin. From [2] again, gcc older than 4.4 can generate poor code, but there is no mention that correctness is a problem. 4. Helper functions In a couple proposed patches, there has been some interest in abstracting some SIMD functionality into functions to hide implementation details away. I agree there are cases where that would help readability and avoid duplication. Given all this, the anti-climax is: it seems we can start with something like src/include/port/simd.h with: #if (defined(__x86_64__) || defined(_M_AMD64)) #include <emmintrin.h> #define USE_SSE2 #endif (plus a comment summarizing the above) That we can include into other files, and would be the place to put helper functions. Thoughts? [1] https://docs.microsoft.com/en-us/archive/blogs/reiley/macro-revisited [2] https://stackoverflow.com/questions/56049110/including-the-correct-intrinsic-header -- John Naylor EDB: http://www.enterprisedb.com